pydbus refuses to coerce a plain Python ``str`` value into a
``GLib.Variant`` when the slot is declared with ``QVariantMap``
(D-Bus ``a{sv}``), surfacing at runtime as
``MPVMediaPlayer.play failed: argument value: Expected GLib.Variant,
but got str`` on every video play. Wrap each option value via
``_marshal_dbus_options`` so the call site hands pydbus a
``dict[str, GLib.Variant]``. Test fixture monkeypatches the helper
to identity so existing options-dict assertions keep working;
a regression test verifies the wrap actually produces ``GLib.Variant``
instances (caught the same way the live error surfaced on the
x86 testbed deploy).

…tats file

Diagnostic for HEVC drm-copy silently SW-falling-back under the
render API on Pi 4. Subprocess mpv with --vo=null --hwdec=drm-copy
engages the rpi-hevc-dec block via /dev/video19 + /dev/media0 fine,
but the embedded libmpv path reports hwdec-current= empty for every
HEVC clip while the same 1080p60 H.264 + v4l2m2m-copy engages
cleanly. Verbose log + persisting MPV_EVENT_LOG_MESSAGE rows to
mpv-stats.log lets us see exactly which hwdec init step is failing
without depending on AnthiasWebview's stderr (which sh.Command on
the Python side captures into an unreachable bytes buffer).

QOpenGLWidget renders into an offscreen FBO that Qt's compositor
then blits into the window — two copies per frame on top of
libmpv-render's GL upload. On Pi 4 V3D 6.0 that pushed 1080p60
H.264 to 2973 drops/60 s even with HW decode confirmed engaged
(``[vd] Using hardware decoding (v4l2m2m-copy)``); the bottleneck
was VO throughput, not the decoder. ``QOpenGLWindow`` with
``NoPartialUpdate`` swaps the native window's default framebuffer
directly — same path mpv's own Qt example uses.

VideoView changes from ``QOpenGLWidget : QWidget`` to
``QOpenGLWindow : QPaintDeviceWindow`` (QWindow tree, not widget
tree). ``View`` wraps it with ``QWidget::createWindowContainer``
so MainWindow's existing widget-tree layout (dual QWebEngineView
pair + image canvas + video) stays intact. Visibility / geometry
toggle on the container; the GL render context lives on the inner
QWindow and persists across show/hide so repeated plays don't
re-initialise ``mpv_render_context``.

``QT += opengl`` replaces ``openglwidgets`` in both
``AnthiasWebview.pro`` and ``tests/tests.pro``. 8 QtTest cases
still pass (mpv handle lifecycle, option round-trip, key
normalisation, stop idempotence, video-rotate passthrough), and
the offscreen-platform "QOpenGLWidget not supported" warning that
fired on the dev host is gone — QOpenGLWindow doesn't have that
restriction.

…ndow"

This reverts commit bd558c9.

The libmpv-embedded path engaged HW decode correctly on all 4 Qt6
boards but didn't move Pi 4 frame drops below the subprocess-mpv
baseline (562–2973 drops/60 s, same range as PR #2885). Real-device
verbose mpv logging confirmed the decoders engaged; the bottleneck
was V3D 6.0 fillrate through libmpv-render → QOpenGLWidget FBO →
Qt-compositor → eglfs swap. Skipping the FBO indirection by porting
to QOpenGLWindow crashed under eglfs's single-native-window-per-
process limit (reverted at f057198).

QtMultimedia + gstreamer is the next try:

- ``VideoView`` rewritten around QMediaPlayer + QVideoWidget +
  QAudioOutput. QVideoWidget paints inside MainWindow's existing
  eglfs native window, so we don't trip the single-window
  restriction. Stats logger keeps the same /data/.anthias/mpv-stats.log
  schema (INIT / LOADFILE / PLAYING / SAMPLE / END_FILE) with a
  drop estimate computed from container_fps × elapsed − frames-
  delivered (QVideoSink::videoFrameChanged counter).
- ``QT_MEDIA_BACKEND=gstreamer`` is set in the viewer Dockerfile so
  Qt picks the gstreamer backend over its ffmpeg one — the rpi
  ``v4l2slh264dec`` / ``v4l2slh265dec`` elements (in rpt3
  ``gstreamer1.0-plugins-bad``, confirmed via ``dpkg-deb -c`` on
  the .deb) route directly to QVideoSink.
- ``docker/_rpt1-ffmpeg-pin.j2`` extends the rpi-archive pin to
  ``gstreamer1.0-*`` + ``libgstreamer*`` so plugins-bad wins from
  rpt3 over stock Debian (priority bump 100 → 1001).
- ``viewer_extra_apt_dependencies`` swaps libmpv2 for the
  gstreamer1.0-{alsa,libav,plugins-{base,good,bad,ugly}} +
  libqt6multimedia6 + libqt6multimediawidgets6 + qt6-multimedia-dev
  set.
- ``MPVMediaPlayer`` Python options shrink to audio-device +
  video-rotate (Pi 4 only). Removed: hwdec, video-sync,
  vd-lavc-threads, the _PI_HWDEC_BY_CODEC table, _probe_video_codec,
  _pi_hwdec_for_uri. Codec dispatch is now gstreamer's job.
- Python tests drop the ~12 per-codec / ffprobe-dispatch tests;
  C++ tests drop the mpv_get_property_string round-trip in favour
  of QMediaPlayer construction + option-passthrough assertions.
  Codec-gate symmetry test replaced with "gate codecs ⊆
  {h264, hevc}" — broader, catches a relaxation of the upload
  gate at the same time.

Pi 4 perf gain is unverified — Pi 4 testbed went offline
mid-session (along with Pi 5 and Rock Pi 4). Real-device
validation pending.

… env

End-to-end test on x86 caught two bugs:

1. ``player->setSource(QUrl(uri))`` parsed local paths
   (``/data/anthias_assets/...mp4``) as scheme-less relative URLs.
   QMediaPlayer's ffmpeg backend silently refuses to load them — no
   error fired, position stayed at 0 for the whole 12-second
   asset_loop wait. Use ``QUrl::fromLocalFile`` when the URI starts
   with ``/``; absolute URLs (``http://``, ``file://``, ``rtsp://``)
   round-trip through ``QUrl(uri)`` as before.

2. Qt 6.8 dropped the gstreamer multimedia backend upstream (6.5+).
   Debian Trixie ships only ``libffmpegmediaplugin.so`` in
   ``/usr/lib/.../qt6/plugins/multimedia/``. ``QT_MEDIA_BACKEND=
   gstreamer`` silently fell back to ffmpeg, which means our path
   is fundamentally similar to the libmpv-via-render-API attempt
   (ffmpeg decoder → QtMultimedia GL upload). The plan's "zero-copy
   DMA-BUF through gstreamer" claim doesn't hold on this Qt version.

   Pin ``QT_MEDIA_BACKEND=ffmpeg`` explicitly so a future Qt that
   re-introduces the gstreamer backend doesn't silently switch us.
   Keep the ``gstreamer1.0-*`` apt set because the +rpt1 libavcodec
   the ffmpeg backend dlopens IS configured with v4l2_request /
   v4l2m2m hwaccels, and ``gst-launch-1.0`` / ``gst-inspect-1.0``
   stay useful as hardware diagnostics.

Pi 4 perf gain still unverified — same architectural ceiling
applies. The PR continues as architectural cleanup (single Qt
process, no mpv subprocess, smaller option dict) while we measure.

The earlier commit added the full gstreamer1.0-* plugin set under
the assumption QtMultimedia would route through ``v4l2slh*dec``
elements. Qt 6.8 dropped that backend upstream — only
``libffmpegmediaplugin.so`` ships in
``/usr/lib/.../qt6/plugins/multimedia/``. Decode actually goes
through libavcodec directly (the +rpt1 build still carries
``--enable-v4l2-request`` / ``--enable-v4l2-m2m``, so HW decode
still reaches the rpi-hevc-dec + bcm2835-codec hardware), and the
gstreamer packages were dead weight: ~400-500 MB of image bloat
that pushed the Pi 4 viewer image past the SD card's free space
during ``docker load`` (disk hit 0 % before the load completed).

Drop the gstreamer set + the ``QT_MEDIA_BACKEND=ffmpeg`` env
(default selection arrives at ffmpeg anyway, no need to pin). Also
trim ``_rpt1-ffmpeg-pin.j2``'s pin string back to the ffmpeg /
libav* family.

view_video in src/anthias_viewer/__init__.py:495 calls
``view_image('null')`` AFTER ``media_player.play()`` to clear any
leftover image / webpage background while the just-started video
holds the foreground. My loadImage handler was unconditionally
calling ``hideVideoSurface()`` (→ ``videoView->stop()``) on every
loadImage, including the ``'null'`` sentinel, which stopped the
video 66 ms after PLAYING fired.

On Pi 4 this was mostly invisible because the bcm2835-codec
decoder is past its critical init phase at 66 ms; the player
recovered. On Pi 5 the Hantro G2 + CMA allocation for 4K60 HEVC
is still mid-init at 66 ms, the stop() interrupts it, and the
QMediaPlayer leaves position pegged at 0 for the entire 60 s
asset_loop window — black screen, 3600 dropped frames. Subsequent
plays of the same clip work because partial decoder state
persists.

Skip hideVideoSurface when preUri == 'null'. Real image URIs
still tear down the video.